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I. Motivation for the Restructuring 

During our work in providing some new features for the Air 
Force, we needed to create a new type of device driver which 
woula be controlled by the I/O Coordinator. However, due to 
the current structure of the driver software, we found this 
task very difficult. Specifically, it would be necessary to 
introduce a new operator response at 10 Daemon initialization 
time and write new software to be executed for the remainder 
of the process. Limitations within existing modules, due to 
the assumptions about possible device types and how they would 
be controlled, prevent their use in new drivers. 

It occurred to us that if we are having this trouble now, 
others will have the same problem in the future as more 
devices* which could be controlled by a device driver, ^re 
aaaea to the system. For example, the MIT/IPC effort to write 
a spooling tape dim with a command interface shows one attempt 
to add a tape driver within the current structure. In the 
future we may want to add plotters, COM or other devices, 
which may be controlled by queued requests. 

Therefore, now that we have a need for a new driver type, it 
will be easier to generalize the driver structure at this time 
rather than rewrite even more software in the future. This 
MTB addresses this generalization with the following goals! 

i. Allow the easy addition of new driver software for new 
devices (or device classes) without recompiling existing 
software or changing the operator interface except for 
device specific functions. 

2. Seoarate the driver control software into generic 
functional modules for easy maintenance and sharing or 
tailoring to new drivers. 

3. Generalize the specifications of devices and device classes 
within Io_daeraon_parms allowing parameters to determine the 
control module which will be called. 
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II. Problems with the Current Driver Software 

The statements made in the first paragraph were very general, 
so the following is presented as further Justification. The 
reader may wish to look at the source programs in 
bound_iodd_.s. archive in the tools library to clarify some of 
the specifics. 

1. All modules of the driver software assume either print or 
pjnch device specifics throughout. Extensive checking of 
new "switches" would be required if this software were to 
be used for new devices. 

2. The format of a user request assumes printer or punch 
control functions which may not apply to other devices. 
(Only a small amount of aata in the front of the structure 
is shared by the 10 Coordinator.) 

3. Current data areas in iodd_static assume that there will be 
no more than two logical devices per physical device (e.g., 
the printer and punch of a mohawk). This makes the 
aoaition of new multi-function devices more difficult. 

*♦ . Only the remote, module knows how to find the two logical 
aevices associated with a mu I t i -f unction device using the 
"remote_tab" (which also limits the logical devices to 
"prt_name" and "pun_name") . This forces the single 
function ana mu I t i-7unction device initialization 
algorithms fo be completely different. The limitation of 
multi-function devices to remote, is also seen in 
io_oaemon_parms. 

5. The module input_cmd_, which does general driver command 
processing, assumes that only remote, could have device 
SDecific operator commands. 

6. To share code between the print and punch requests for 
local ana remote drivers (and for historical reasons), the 
module out put_request_ carefully formats printer head and 
tail sheets for punch requests and writes them through the 
di scard_outpu t_ aim. 

7. The module iodd_l isten_, which dispatches a user request 
(from the coordinator) to be processed by the driver, 
assumes that only one module knows how to handle the 
request, no matter what device is to be used. 

In summary, the 10 daemon driver is structured as an output only 
driver which knows how to print and punch with on site or remote 
(mohawk) devices. The dim_name in i o_daemon_parms allows some 
flexidility, but not enough for completely new functions with the 
existing software. 
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I II. Proposed Changes 

At initialization time for any IO.SysOaemon the operator is 
asked whether the process is to be a "coordinator, driver, 
remote or cards." This will be changed to allow only 
"coordinator or driver", moving the distinction between remote 
and local drivers until later in the process so we can use 
some common general procedures for assignment of devices and 
device classes. ("cards" does not have to run as 
IO.SysOaemon. The removal of the "cards" option is the 
subject of another MFB.) 

The current iodd_overseer_ will taKe on additional functions 
from io_aaemon_driver_» remote_» and driver_init_, providing 
centralization of all initialization code and a uniform 
approach to searching the lod_device_tab. This is a necessary 
step since the "remote" response has been removed (above) and 
we must now determine the existence of multiple logical 
devices differently. 

To accomplish this, we will introduce the concepts of major 
and minor devices to io_daemon_parms and to the 
iod_device_tab. A "major oevice" is a generic name associated 
with a physical device. A "minor device" is a generic name of 
a logical device associated with a major device. There may be 
up to ten (101 minor devices per major device. (Ten is an 
aroitrary number chosen to limit table size and still allow 
f lexibil ity.) 

Each major oevice corresponds to a physical piece of hardware 
attached to the process through a physical I/O or TTY channel. 
The per oevice attributes such as channel, dim, driver module, 
device dial id (for remote devices), and control terminal dial 
id (see MTB 129), are associated with the major device. Each 
minor device then has the device type and default device class 
associated with it. 

Now, when the operator is asked to give the "aevice name and 
optional device class," he will specify the major device name 
(assume no device class for the present). The module 
i ood_overseer_ will then proceed by requesting the 10 
coordinator to associate each of the minor devices which 
belong to the major device with the driver process. Separate 
driver status segments will be created for each minor device* 
The driver may now behave as separate logical drivers for each 
minor device at its discretion. The driver may even ignore 
one or more of the minor aevices. This does not tie up 
resources unnecessarily since they are all part of the same 
physical device and can only be attached to one process at a 
t ime. 
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There are two cases which can arise when the operator 
specifies the optional device class. First, when there is 
only one minor device for the major device (e.g.* a printer 
connected to the IOM) the specified device class will override 
the default device class defined in io_daemon_parms. There is 
no ambiguity in the operator's intent in this case. The 
second case occurs when there are multiple minor devices for 
the major aevice. Currently, only the aefault device class 
for each device may be used. Since we do not Know to which 
minor device the optional device class should apply, we 
propose that the operator be asked if the specified aevice 
class is to be associated with each minor device, in turn, 
giving the operator the ability to choose a different device 
class or retain the default for each minor device. This 
approach is chosen to simplify the operator interface for the 
common situation (in fact, it will not change at all) and 
still allow the operator to switch the processing of any 
device class to any driver which can handle it, local or 
remote . 

A new aata item will be added to io_daemon_parms , called 
"driver_module". This will be associated with the major 
aevice ano will define the program to be called by 
i odd_overseer_ after the initial driver-coordinator protocols 
are completed. By convention, there will be standard entry 
point names in the ariver moaule for initialization, request 
processing, command processing and condition handling. Entry 
variables will be added to iodd_static so each of the common 
driver subroutines (e.g., ioda_listen_ and input_cmd_) can 
have standard calls to perform driver specific functions. 

New driver modules may need new data from io_daemon_parms. 
Therefore, to avoid modifying several programs and data 
structures for each new driver, the method of specifying the 
major ano minor aevice attributes in the io_aaemon_parms file 
needs to be generalized. Only those attributes which are 
needed during the common initialization of all drivers will 
have keywords in the parms tile. Those attributes which may 
be more dynamic, on a per driver module basis, will be 
described by a quoted string after the new keyword "args". 
This allows the addition of new driver control moaules to be 
completely parameteri zed. . .no recompi lat ion should be 
necessary. 

The format of the user request oata structure which is stored 
in the message segment must also become more general. This 
will allow cevice options ano driver options to be tailored to 
each driver module rather than changing one include file and 
recompiling all modules which use it (currently there are nine 
(9) external procedures which reference dprlnt_msg. inc I .p 11) . 
We will establish a standard header structure which will 
define that part of the request data which must be known by 
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the coordinator as well as all drivers. The "pr int_punch" 
variable will be changed to indicate the driver module which 
is expected to perform the request. Only the driver module 
and the command setting the value need to agree on the value 
(but it must be unique among driver modules). Each driver 
module will check to ensure that the request is meant for that 
particular driver. Then the remainder of the request data can 
be interpreted on a per driver module basis. The coorainator 
does not care how long the request is? it only needs the 
time, pathname* delete switch and version of the request 
heaaer. 



IV. Summary 

These proposed changes proviae the structure needed to 
completely generalize the driver software. A new type of 
device driver can be added by writing a driver module which 
meets the conventions and knows how to control the device. 
Then the io_oaemon_parms file can be edited by an 
aoministrator to induce the new device* device class and 
other attributes. 

The operator interface will not change for the new driver 
except for new driver specific commands. Each driver can make 
use of the same overseer* which will handle all initial 
ari ver-coordinat or protocol. Some of the driver subroutines 
can be directly used by the new driver module without changes? 
others can be easily tailored to meet new requirements. 

These changes imply that almost every module of the current 
driver process will be either rewritten* restructured or 
removea. Driver modules for controlling the printer* punch 
and mohawk devices will have to be written. At installation 
time* all driver modules and lo_daemon_parms will have to be 
replaced since they will now be incompatible with older 
versions. 
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APPENOIX I 
10 (DAEMON PARMS KEYWORD LIST - OROEREO BY OCCURENCE 

/* PL/I style comments may appear anywhere in the parms file */ 

There are two keywords which specify global values for the 10 
coordinator ana must appear at the beginning of the parms file! 

Time: Defines the time in minutes that each 

completed request will be saved to allow for 
restarting. Normally* a delete option will 
not be completed until after this time has 
elapsed* 

Max_queuesJ Defines the maximum number of message segment 

queues to be created or read for each queue 
group defined* 

The next group of keywords are used to define the devices which 
driver processes may use. The device data is used oy the 10 
coordinator to builo the "device_tab I e". All device definitions 
must appear ahead of the aevice class definitions. 

Device: Defines the name of a major device 

(required - 32 char max) 

dri ver_modul e: Defines the pathname or search name of the 

program which runs the device 
(required - 168 char max) 

args: Defines an arbitrary character string for the 

driver module to decode which describes the 
major device. (optional - 128 char max) 

channel: Defines the I0M channel of the device for 

direct attachment by the process. This must 
be specified if the dev_dial_id keyword is 
omitted and must be omitted if the 
dev_dial_id is specified. (8 char max) 

dev_dial_id: Defines the dial_id to be used if the device 

is to be dialed to the process over a tty 
channel. Immediate attachment to a hard 
wired tty channel will be specified in the 
Qial table if aesired by the site. This 
keyword may not oe specified if the channel 
keyword is used. <8 char max) 
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ctl_dial_id* Oefines the dial id to be used for the 

control terminal to be aialed to the process. 
Optional - if omitted* no control terminal is 
required for the driver, 
(optional - 8 char max) 

ctl_device: Oefines the device name expected for the 

attachment of the control terminal. Example* 
ctll for the message coordinator, netl03 for 
the arpa net, ttyi<+2 for the 0N355. This 
keyworc is primarily included for the message 
coordinator since there will be no check to 
ensure that this is the actual channel 
assigned. (optional - 8 char max) 

minor_devices Oefines tt)e name of a minor device associated 

with the last named major device. If omitted* 
the minor device name is taken to be the same 
as that of the major device, 

(optional - 32 char max) 

args* After the minor device keyword, args defines 

another arbitrary character string used by 
the driver module to describe the minor 
device. There may be one args keyword per 
minor device. If omitted for any minor 
device, a null character string is assumed, 
(optional - 128 char max) 

aef aul t_c lass* Oefines the default device class to be used 

for this minor device. If omitted, the 
operator must specify the device class during 
initialization. (optional - 32 char max) 

like* This keyword is used to reduce the amount of 

text in the parms file when there are several 
major devices with similar attributes. All 
missing attributes in the specification of 
the major device, including minor device 
names, are taken from the major device name 
which is the value of the keyword, 
(optional - 32 char max) (Notes the major 
device named must have been previously 
specified if the file.] 

The following keywords define the device classes used by the 10 

coorcinator ana drivers. The device class definitions must 

follow the definitions of the devices to help simplify the 
parsing of the parms file. 



-7- 



MTB-i'+'t Multics Technical Bulletin 

De\/ice_cl ass: Defines the name of a dynamic device class. 

(required - 32 char max) 

devices Defines a minor device which may process 

requests of the last named Device.c lass. One 
or more instances of this keyword must be 
associateo with a device class. The value is 
of the form major. minor to distinguish 
between minor devices of the same name in 
different major devices. If only one 
component is specified as the value* then 
major. major is assumed. 

(required - 65 char max) 

driver_userios Defines the only process group id which may 

be used to handle requests in this device 
class. If omitted* IO.SysDaemon is assumed. 
A personid of * is allowed* but the projectid 
must be specified. (optional - 32 char max) 

accounting* Defines the pathname of the accounting 

procedure to be used for the driver. If 
omitted* or if the value of "system" is 
specified* the standard system accounting 
procedure will be used. The accounting 
procedure specified must be found during 
process initialization* or the driver will 
abort. (optional - 168 char max) 

queue_group: Defines the message segment queues to be used 

for requests in this device class. If 
omitted* the queue group will be taken to be 
the same as the device class. Example! 
printer means use the printer_N.ras queues, 
(optional - 32 char max) 

min_access_c lass: Defines the lowest access class request which 

a driver of this device class may process 
from the specified queue group. If omitted, 
the system_low access class will be assumed. 
The string must be acceptable to the 
convert_authorizat ion_ subroutine, 

(optional) 

max_access_class» Defines the highest access class request 

which a driver of this device class may 
process from the specified queue group. The 
access authorization of the driver must be 
equal or greater than this value. The 
max_access_cl ass must be equal or greater 
than the min_access_c lass according to the 
rules of the access isolation mechanism. If 
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omitted* the value of min_access_c lass is 
assumed. The string must be acceptable to 
the convert_author ization_ subroutine, 
(optional ) 

min_banner! Oefines the lowest access class to be used in 

marking the output generated by a driver 
process. If omitteo, the value of 
min_access_class is assumed. The string must 
be acceptable to the convert_authorizat ion__ 
subroutine. (optional) 

End: This keyword has no value associated with it. 

It only serves to define the end of the parms 
file, (required) 



-9- 



